Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arch/xtensa: arch_cpu_idle cleanup #64760

Merged
merged 3 commits into from
Nov 20, 2023

Conversation

RanderWang
Copy link
Contributor

move some intel cavs platform code to intel platform folder

andyross
andyross previously approved these changes Nov 6, 2023
Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I like this very much at a level of code hygiene and platform encapsulation. So it's a +1. But I'm going to repeat my question from earlier, because I really do hope we can find an answer:

Are we absolutely, 100% sure that this is a hardware issue that only affects Intel audio DSPs?

Upstream SOF on Intel is the original source for this trick, but the way it's documented there seems to imply that it's a more general bug with Cadence IP, even though no one else seems to know about it. If that's true, then we want this to stay in the arch layer so that affected SOCs from all vendors can take advantage of it.

So... are we? If not, can we get someone at Intel to ping Cadence for a proper errata reference or something?

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that's true, then we want this to stay in the arch layer so that affected SOCs from all vendors can take advantage of it.

So... are we? If not, can we get someone at Intel to ping Cadence for a proper errata reference or something?

Mmmmm... shouldn't the next step be for someone OTHER than Intel to reproduce the issue first? I mean it feels at least "awkward" for User X to ask common vendor A about User Y issues.

FWIW I found Cadence support very responsive in this other, unrelated toolchain issue:

@@ -180,6 +180,52 @@ void pm_state_exit_post_ops(enum pm_state state, uint8_t substate_id)
}
#endif /* CONFIG_PM */

#ifdef CONFIG_ARCH_CPU_IDLE_CUSTOM
/* xt-clang removes any NOPs more than 8. So we need to set
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/* xt-clang removes any NOPs more than 8. So we need to set
/* xt-clang removes any NOPs more than 8. So we need to set

Please provide at least one xt-lang version that with confirmed reproduction. This workaround should refer to a proper issue number but for now the mere output of xt-lang --version will already be infinitely better than nothing.

If there was a past discussion in https://github.com/thesofproject/sof about this then also add the link. Toolchain issues are incredibly time-consuming so the last thing they need is incomplete information.

I realize you're "only" moving an existing comment but as noted by @andyross this PR does far more than just re-organizing code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @dcpleung was the one who discovered that particular optimizer misfeature, likely on the MTL toolchain?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the xt-clang I used exhibited the same behavior of "ignoring" NOPs beyond 8.

@RanderWang
Copy link
Contributor Author

RanderWang commented Nov 7, 2023

So, I like this very much at a level of code hygiene and platform encapsulation. So it's a +1. But I'm going to repeat my question from earlier, because I really do hope we can find an answer:

Are we absolutely, 100% sure that this is a hardware issue that only affects Intel audio DSPs?

Upstream SOF on Intel is the original source for this trick, but the way it's documented there seems to imply that it's a more general bug with Cadence IP, even though no one else seems to know about it. If that's true, then we want this to stay in the arch layer so that affected SOCs from all vendors can take advantage of it.

So... are we? If not, can we get someone at Intel to ping Cadence for a proper errata reference or something?

For LX6, WAITI instruction has some requirements, each vendor may have different solution to meet them. Due to intel dsp clock gating method and WAITI requirement, Intel audio hw use this workaround so that no hw hang would happen. Please check internal issue about the hw detail.

updated : internal number 1804185050

tmleman
tmleman previously approved these changes Nov 7, 2023
@@ -173,4 +173,11 @@ endif # XTENSA_MMU

endif # CPU_HAS_MMU

config ARCH_CPU_IDLE_CUSTOM
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be xtensa specific, please move it up so any other architecture can do the same if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nashif updated, thanks

Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I think this is a good cleanup, but I think this has to be enabled by default for affected targets.

bool "Custom arch_cpu_idle implementation"
default n
help
This options allows applications to override the default arch idle implementation with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this. Why would this be an application level override? It seems this is a board/soc specific requirement and if you buiild for these targets, the custom functions has to be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kv2019i I tested cavs2.5 and didn't find any issue. I traced this issue which was found on cavs1.8 platforms in 2017 and then these patches was applied. I don't think it still exists on cavs2.5 so I don't enable it with cavs2.5. I reserve it since It will make effect when cavs1.8 platform are supported.

arch/xtensa/core/cpu_idle.c Show resolved Hide resolved
arch/xtensa/core/cpu_idle.c Show resolved Hide resolved
arch/xtensa/core/cpu_idle.c Outdated Show resolved Hide resolved
Each arch platform may has a general arch_cpu_idle implementation but
each vendor may has a custom one, so this config will be used for vendor
to override it.

Some workarounds were introduced for intel cavs2.5 platform bring up.
It is not general so move them to platform code.

Signed-off-by: Rander Wang <rander.wang@intel.com>
Cavs platforms starts from Apllolake to Raptorlake. Some of them need some
workaround for arch_cpu_idle so create a bespoken one. Each workaround is
configured by kconfig setting.

Signed-off-by: Rander Wang <rander.wang@intel.com>
@RanderWang
Copy link
Contributor Author

remove "no optimization"

Some workarounds were introduced for intel cavs2.5 platform bring up.
It is not general so move them to platform code.

Signed-off-by: Rander Wang <rander.wang@intel.com>
@RanderWang
Copy link
Contributor Author

@dcpleung move CONFIG_XTENSA_CPU_IDLE_SPIN and CONFIG_XTENSA_WAITI_BUG to intel side. Thanks!

@RanderWang RanderWang requested a review from nashif November 17, 2023 06:52
@RanderWang
Copy link
Contributor Author

@dcpleung could you help to review it ? thanks!

Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @RanderWang , looks good now!

@carlescufi carlescufi merged commit 9549012 into zephyrproject-rtos:main Nov 20, 2023
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Xtensa Xtensa Architecture platform: Intel ADSP Intel Audio platforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants